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INTEGRATED METHOD OF INTERNATIONAL TRADE 

This application is a continuation in part of US patent application Serial 
No. 09/969,368, entitled "International Trade System," filed October 1, 2001, under 
applicants' docket no 10012318-1, which is incorporated herein by reference for all 
purposes. 

The present invention relates generally to international trade, and more 
particularly, to integrated systems, software and related business methods for handling 
international trade in a multitude of trade scenarios. 

BACKGROUND OF THE INVENTION 

International business transactions frequently lead to issues in the 
international transportation of goods. The transactions can take place between related 
or unrelated business entities, any of whom could be barred from international trade by 
certain countries or with their citizens and corporations. The goods can be finished 
products for the consumer market or components for use in manufacture. They 
likewise can be environmentally sensitive or toxic goods, goods restricted for security 
reasons, and/or goods packaged in ways that must be reported in certain countries. The 
goods can be subject to export license requirements, import duties, and customs 
regulations. These issues can arise with each international border crossed by the goods, 
even goods that are simply in transit through a jurisdiction. 

For example, goods are often manufactured in one country and then 
shipped to and sold in another country. Once the goods are manufactured, the shipping 
entity prepares a billing invoice, which includes billing information such as the name 
and address of the shipping entity, the name and address of the purchasing entity, the 
name and address of the consignee, a marketing description of the goods, the value of 
the goods, and the quantity of the goods. The billing invoice is either attached to the 
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goods before they are transported to the consignee or electronically sent to the 
consignee. 

Upon arrival of the goods at the port of destination, the carrier's 
representative notifies the customs broker that the goods have arrived. The goods are 
5 temporarily held in a bonded area until released by customs. A customs broker is hired 
by the purchasing entity to prepare and submit the customs declaration. The customs 
broker prepares the customs declaration using information on the billing invoice, 
airway bill, packing list, and other related documents. The customs declaration is a 
form that is unique to each individual country and includes information that describes 
1 0 details about the goods or shipment to the particular country. For example, the customs 
declaration will include a classification number (also referred to as a harmonized tariff 
schedule (HTS) number) representing the category of the goods, a commercial 
description of the goods, and the value of the goods. 

The local HTS is used to assist customs brokers with classifying goods. 
The local HTS includes a list of goods with a corresponding classification number. 
Generally, each classification number is 10 characters in length, where the last 4 
characters are determined by each country's local interpretation of the goods. 
Accordingly, each country has its own unique HTS, e.g., the Mexico HTS. With each 
country having its own interpretations of the HTS, several different classification 
numbers can be assigned to the same type of goods. Hence, it is difficult to have a 
centrally assigned classification number system. To make the classification task even 
more difficult, the classification numbers are periodically modified. 

After the customs declarations are completed, the customs broker calls 
the customs inspector or stands in a line waiting for the customs inspector to review the 
25 customs declaration and the accompanying documents and to clear the shipment. 
Alternatively, the customs broker may be allowed to electronically submit the customs 
declaration for review and clearance of the shipment. 
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A typical commercial shipment could involve nine different participants, 
20 separate documents, 35 customer- vendor interactions and four modes of transport. 
It could require weeks or months to complete, and can cross several international 
borders. Thus, an elaborate supply chain including manufacturers, distributors, retailers 
5 and transportation service providers including freight forwarders, carriers and customs 
brokers has developed around the world. The resulting global transportation industry 
is one of the largest and most complex in the world, requiring a high level of expertise 
in a variety of transportation issues that vary from legal jurisdiction to jurisdiction. 

In this complex marketplace of services, buyers and sellers are frequently 
10 inexperienced, lacking knowledge of the wide variety of legal requirements placed on 
international transportation by each country. As a result, a large corporation with 
thousands of buyers and sellers world wide can have extreme variation in its practices. 
This potentially leads to noncompliance or inconsistent compliance with various 
national laws, excessive delivery times, additional expenses in customs, shipping and 
15 brokering, and unclaimed drawbacks from refundable duties. Furthermore, because 
transportation procedures are not consistently maintained, little quality control can be 
exercised in monitoring preferred procedures and selecting better-performing service 
providers. A noncompliance with national laws is particularly important, as it can lead 
to both extreme financial penalties and the arrest and incarceration of people ignorantly 
20 conducting transactions violating the law. 

Additionally, costs and delivery time are highly variable, and 
predictability is limited by a lack of consistent procedures and historic information. 
Thus, purchasers often must make purchasing decisions without a realistic 
understanding of the total cost and/or time to delivery. 

25 Presently, interaction between importers, exporters and their service 

providers is primarily conducted via paper, phone and facsimile. The industry lacks 
industry-based universal formats and standards, and customers use different sets of 
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processes with each service provider. Information from global logistics typically 
remains disconnected from enterprise systems designed to drive efficiencies across 
global supply chains. 

In attempting to automate and standardize processes, numerous 
5 transportation service providers have developed automated processes within their areas 
of expertise. Such efforts have produced tax services, shipment tracking services, 
customs invoicing services, duty calculation services, customs classification services, 
import regulation services, export regulation services, and a large host of other 
applications. For a customer to take advantage of each such application, that customer 

10 (^g., buyer, seller or related service provider) must know to use the application, 
purchase access to the application, learn to use the application, and provide all relevant 
information for the application to use. Additionally, because these solutions can be 
regional in applicability, and because these solutions can be inferior for some types of 
transactions or locations, while superior for others, their consistent use by a user 

15 familiar with just the one application can be limited in effectiveness by its inferiority 
when used for other jurisdictions. 

In some cases, providers are bundling these point solutions into packages 
of related software. For example, there are bundles of software configured for tax 
calculation, bundles of software for landed cost calculation, bundles of software 
20 configured for export issues and bundles of software configured for import issues. 

These bundles combine specific point solutions, and therefore adopt their 
limitations and weaknesses. They each commonly operate without consideration of 
factors from numerous other substantive or jurisdictional areas. For example, packages 
for estimating costs cannot typically consider the incremental costs incurred in export 
25 (e.g., license requirements and restricted party limitations), import (e.g., duties and 
environmental limitations), logistics (e.g., shipping costs that vary based on a particular 
customer's pricing agreements), taxes (e.g., customer preferences for claiming "assists" 
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and other tax related activities) and other such issues. Furthermore, even presuming 
that all customers could be trained and educated on the use of each such bundle, 
separate business arrangements and technology connections need to be established and 
maintained for each bundle, adding to the overall cost of conducting international 
transportation of goods. 

Additionally, accessing individual bundles does not provide the 
integrated information to accurately predict total transaction cost and delivery time. 
Thus, purchasers and/or sellers continue to take risks on cost and delivery time, or they 
avoid the purchase of goods in international trade. 

Accordingly, there has existed a need for an improved system for 
international trade and the conduct of international business transactions. Such a 
system would preferably provide for improved speed, accuracy, legality and 
consistency. Preferred embodiments of the present invention satisfy these and other 
needs, and provide further related advantages. 

SUMMARY OF THE INVENTION 

In various embodiments, the present invention solves some or all of the 
needs mentioned above, providing systems, software and related business methods for 
handling the international transportation of goods. 

The in certain embodiments, the inventive method relates to includes a 
method of conducting an international transaction in goods between a buyer and a 
seller. The buyer has an intended destination for the goods, and the seller has location 
that the goods either exist or will be manufactured. The invention includes a server that 
identifies a source country for the seller's goods and a buying country for the buyer's 
destination for the goods. Based on this information, the server queries a shipping 
module to calculate a total shipping cost for shipping the goods along a shipping rout 
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to the service level. It also queries a brokering module to calculate a total brokering 
cost for brokering the goods along the shipping rout, and a tax module to calculate a 
total tax cost for the sale and transportation of the goods. 

The invention features the server providing a total cost to the buyer, the 
5 total cost including a sale price, the total shipping cost, the total brokering cost and the 
total tax cost. The buyer provides the server with an authorization to conduct the 
transaction, preferably in response to the total cost. The server then transmits shipping 
instructions to a carrier, preferably based on the calculated shipping costs, and transmits 
customs invoice information to a customs broker. 


10 Advantageously, using these features the buyer can make purchasing 

decisions based upon promptly provided actual cost information rather than historic 
data. Furthermore, buyers worldwide can take advantage of this feature, without 
investing in expensive training for every buyer or outsourcing the purchasing activities 
to an uninterested purchasing service. Furthermore, it provides for consistent and 

15 predictable transactions that safely meet various legal requirements on a consistent 
basis. 


The invention further features the receiving and tracking status updates 
regarding the status of the goods in transport to the buyer. Using this information, the 
server can provide status reports in response to status requests received regarding the 

20 status of the goods. Typically these status requests will come form the relevant parties. 
Advantageously, the frequent updates provided during the importation of goods 
provides both for better planning and early detection of delays, which can be very 
advantageous for the buyer. Such tracking is substantially more difficult when a buyer 
either tries to manage all service provider contacts itself, or when a buyer disconnects 

25 from the purchase process by using a purchasing service. Additionally, the information 
supports the accurate analysis of service provider performance data, thus allowing the 
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buyer to purchase services from the service providers that offer the most consistent and 
high-quality level of service. 

The invention also features the querying of transaction-restriction 
modules to identify any national restrictions that would make the transaction illegal. 
5 These queries, which are preferably done more than once, and which are done at any 
time legally required, assure that the transaction will not be completed if any national 
restrictions making the transaction illegal are identified. 

The invention, in many embodiments, is also a system configured to 
operate with both a plurality of internal service engines that operate within the 
protection of a software firewall, and a plurality of external service engines that operate 
outside the firewall. The internal and external service engines are configured to 
provide a variety of separate services that are not fully integrated. The invention 
features an application server module, being configured to selectively send data to, 
receive data from, and/or share data between the service engines. The application 
server module uses this data passing and sharing to selectively operate the service 
engines and integrate their separate services into an integrated service. Any number 
of users having needed of the integrated service can request the integrated service by 
accessing the application server module via an interface module. 

This feature advantageously provides for efficiently meeting users service 
20 needs with reduced costs and better results. In particular, by offering the service as an 
integrated service, the system can avoid significant training of each user, both in 
learning all requirements to fulfill the service needs, and in learning how to separately 
operate each service engine. Integration also provides for both a seamless single point 
of entry, a consistent user interface and intelligently guided operation. Furthermore, 
25 by integrating the applications, there is a significant savings in user time, as the human 
portion of the task is reduced in scope. Additionally, by having an intelligent interface 
that requires all users to deal with every aspect of the service needs, more consistent 
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performance is achieved throughout a large company of users, and in cases where legal 
requirements exist, an improved level of legal compliance by the corporation as a 
whole can be achieved. 

By integrating operations that have a bearing on each other, the features 
5 of the invention also advantageously provide for better record-keeping, and therefore 
superior accountability is achieved. This leads to lower relationship costs and more 
accurate reporting and compliance with laws and objectives. The centralized 
interconnection of the service engines also provides for efficient maintenance and 
simple oversight. Furthermore, modernization and upgrades can be accomplished with 
1 0 minimum effort by swapping service engines, leading to better negotiating power with 
outside providers of service engines. 

The invention further features a service engine communication layer 
connecting the application server to each service engine. The service engine 
communication layer is configured to translate communication protocols to facilitate 
communication between the application server module and service engines that use any 
of a variety of communication protocols. This feature provides for the use of service 
engines from a variety of sources without having to purchase reprogramming services 
from the sources. Furthermore, because the service engine communication layer will 
typically have an extensive selection of communication protocols, many new service 
engines can be integrated without any significant investment of time or effort, giving 
a plug-and-play capability to service engines that are not designed to have it. 

Embodiments of the invention can also feature a router configured to 
place the service engine communication layer in communication with each external 
service engine via a single hole in the firewall. This feature advantageously allows for 
25 improved security, while also minimizing necessary programming efforts to integrate 
new service engines. 
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A combined message broker is also featured in the invention. The 
combined message broker includes an internal within the firewall and an external 
message broker outside the firewall. The internal and external message brokers are 
linked in communication with each other through the firewall. For each interacting 
5 service engines, which is a service engines configured to interact with other interacting 
service engines, the combined message broker is configured to provide a 
communications link between the interacting service engines, and with internal and 
external reference servers. In particular, the internal and external message brokers are 
configured to communicate with the internal and external components (i.e., service 
1 0 engines and reference servers), respectively. Preferably, the combined message broker 
is configured to translate communication protocols to facilitate the interaction between 
the interacting service engines that use different communication protocols. 

Advantageously, these features provide for data communication 
capabilities to interlink the service engines, just as the service engine communication 
layer provides interactive communication capabilities to interlink the service engines. 
Thus, these features also aid in providing the advantages of the application server and 
communication layer, such as reduced costs in training, operations, efficiency, 
maintenance, and modernization. They also provide performance improvements, end- 
to-end transaction visibility, and enable compliance with rules and laws, thereby 
reducing noncompliance issues. 

Other features and advantages of the invention will become apparent 
from the following detailed description of the preferred embodiments, taken with the 
accompanying drawings, which illustrate, by way of example, the principles of the 
invention. The detailed description of particular preferred embodiments, as set out 
25 below to enable one to build and use an embodiment of the invention, are not intended 
to limit the enumerated claims, but rather, they are intended to serve as particular 
examples of the claimed invention. 
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BRIEF DESCRIPTION OF THE DRAWINGS 


FIG. 1 A is the first part of a vertical, cross-functional flow chart of a process for 
conducting an international sale embodying the invention. 

FIG. IB is the second part of the vertical, cross-functional flow chart depicted 
5 in FIG. 1 A. 

FIG. 2 is a block diagram of a TLCL system architecture embodying the 
invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The invention summarized above and defined by the enumerated claims 
1 0 may be better understood by referring to the following detailed description, which 
should be read with the accompanying drawings. This detailed description of particular 
preferred embodiments of the invention, set out below to enable one to build and use 
particular implementations of the invention, is not intended to limit the enumerated 
claims, but rather, it is intended to provide particular examples of them. 

1 5 METHOD OF THE INVENTION 
Online Purchase of Existing Product 

Typical embodiments of the present invention reside in a processes of 
conducting a transaction, including related processes of managing supply chains, 
manufacturing goods, transporting goods, managing legal issues of international 
20 transportation of goods, conducting financial interactions in the support of transactions, 
and combinations of such processes. The invention can be embodied in a process for 
a buyer to accesses a shopping-type web server over a distributed network and purchase 
goods present in one or more warehouses in countries other than the buyer's intended 
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destination for the goods, such as could occur in a consumer transaction. The invention 
can also be embodied in a process for a buyer to accesses e-commerce software and 
order goods to be manufactured in various countries from parts sourced in other 
countries, and delivered to any country desired. 

5 With reference to FIGS. 1 A and IB, a buyer 1 1 uses a browser to access 

a commerce-based Web server 1 3 ("commerce server") over a distributed network such 
as the Internet. The buyer might initially transmit or otherwise provide identification 
information to the commerce server, including information about the form of payment 
and the intended destination. Alternatively, the buyer might shop and anonymously. 
10 The commerce server provides the buyer with access to a database of product 
information displayed in an online catalog format. The buyer proceeds through 
catalog-type interactions 15, selecting items of interest and placing them in a virtual 
shopping cart 17. When the buyer is satisfied with the selected purchases, the buyer 
proceeds to request a check-out procedure 19. 

15 If the commerce server 13 has not yet been provided with shipping- 

destination information, it requests that information from the buyer 1 1 . The commerce 
server then queries 2 1 an inventory-tracking module, including a database, to determine 
if the buyer ' s selected products are available in the buyer' s selected destination country 
or countries. If all or some of the selected products are available in the selected 

20 destination country, a domestic purchase procedure 23 is conducted for those products. 
The domestic purchase procedure can involve the use of a purchasing system that is not 
configured for international trade. Alternatively, the domestic purchase procedure can 
be managed and conducted using the international-trade capable system described 
below, skipping the unnecessary procedural steps such as legal checks and arranging 

25 brokers. 

If some or all of the products are not available in the selected destination 
country, then the buyer 1 1 is provided the option of investigating the possibility of 
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purchasing the products from foreign sources. If the buyer chooses to investigate 
foreign sources for the products, then the commerce server identifies the locations of 
one or more potential foreign sources for the products by querying inventory 
management modules, including one or more databases, as appropriate for the various 
5 countries. For each located foreign source, the commerce server notes the relevant 
country and a warehouse, and generates a message containing data for a hypothetical 
transaction event 24. Each hypothetical transaction message is transmitted to an 
international-trade server 25 configured to manage issues relating to business tax, 
license (export administration), customs and/or logistics (TLCL). 

10 For each hypothetical transaction message, an application server of the 

international-trade server 25 generates a series of messages 27 querying various 
modules such as service engines and/or databases. The application server gathers and 
combines the responses to the queries, forming an information package describing the 
costs and times required for various shipping and brokering options from the country 

15 upon which the hypothetical transaction message was based. 

Some query-messages generated by the application server query service 
engines configured for determining transaction-based restrictions. Based on the 
citizenship of the seller, the citizenship of the buyer, the exporting country, the 
importing country, and any intermediary countries that the goods might travel through, 
20 the service engines examine national-law restrictions on buyers and their related 
parties, sellers, source countries and destination countries. These restrictions could be 
based on criminal history, international relations, and other subjects of national 
concern. The service engines selected by the application server might vary depending 
upon the relevant countries or regions of interest. 

25 Similarly, service engines are queried regarding national limitations 

based on issues such as technology export control, toxic substance control, endangered 
species protection, and the like. In addition to using the above relevant-party and 
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country information, these service engines will typically need to query other service 
engines to determine product classification in each country of relevance. 

The application server will also generate messages querying databases 
containing information on the various parties 1 licenses for conducting the hypothetical 
5 transaction. In particular, selling parties will be examined to assure that they possess 
all necessary export licenses. 

Based upon transportation requirements, and upon the customs laws of 
the countries involved, the various service-activity providers such as forwarders, 
carriers and/or brokers will typically be needed to conduct the export/import operation. 

10 The application server also queries service engines to determine the best combinations 
of service-activity providers and service levels to provide the most cost-effective and/or 
fast delivery of the products to the buyer. With an established set of one or more 
combinations of service-activity providers and service levels, service-related costs are 
established. Preferably the modules establishing the service levels and costs are 

1 5 directly linked with systems of the service-activity providers, or are using databases 
updated by the service-activity providers on a regular basis. 

The application server also generates messages querying databases 
containing information on relevant taxes, including sales tax, value-added tax, duties, 
and the like. 

20 For each hypothetical transaction message 24, replies to all of the 

application server queries are gathered and compiled in the international-trade server 
25. Using this information, the international -trade server develops a set of one or more 
international trade scenarios regarding cost, shipping and availability data 29, each 
scenario being based on a different service level and/or shipping option. The 

25 international-trade server then responds to the hypothetical transaction message with 
this compiled set of information. 
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Preferably, when the commerce server 13 has received a response to 
every hypothetical transaction message, it examines 3 1 whether transaction limitations 
restrict the transaction from occurring. If the transaction fails this restriction test for 
all hypothetical transaction events, i.e., the transaction is restricted from occurring from 
any foreign source country, then the buyer is notified that an international transaction 
is not available 33. However, if the transaction passes the restriction test for one or 
more hypothetical transaction events, i.e., one or more countries from which the 
transaction could occur were identified, then the various international transaction 
options are summarized and provided to the buyer 35. 

The buyer 1 1 is then given the option to order 37 the goods via any of the 
provided international transaction options. If the buyer elects not to purchase the 
products via any of the provided international transaction options, then the buyer 
returns 39 to web pages supporting catalog interactions 15 on the commerce server 13. 

If the buyer 11 elects to purchase the products via an international 
transaction option, then the commerce server 1 3 concludes the interactive portion of the 
purchase with the buyer, allowing the buyer to proceed back to the catalog or onto other 
activities. The commerce server then generates a message containing data relating to 
an actual transaction, being the transaction selected by the buyer. The actual 
transaction message 41 is transmitted to the international-trade server 25, which 
undertakes management of the various issues that must be addressed to complete the 
transaction. 

The application server of the international-trade server 25 preferably re- 
verifies all restriction information by again generating query-messages to service 
engines configured for determining transaction-based restrictions. It also preferably 
re-verifies possession of required licenses. If the relevant national laws require it, the 
international-trade server transmits messages to relevant legal compliance modules 
configured to track legal compliance information for subsequent reporting to relevant 
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national governments. For example, various data such as packaging information, 
environmental information, and the like, are recorded and stored, for later reporting on 
either a transaction-by-transaction or a periodic summary basis to meet packaging and 
environmental laws. A wide variety of other such legal reporting requirements might 
5 be relevant, depending on the laws of the relevant countries. 

Using modules appropriate for the buyer, seller, source country and 
destination country, the international-trade server 25 sends an advance shipping notice 
43 to all relevant parties that require or desire such notice. In particular, notice is 
preferably sent to the buyer 1 1 and the commerce server 13, as well as to a warehouse 

10 45 containing the goods in the selected source country, and to brokers, forwarders and 
shippers 47, as were previously identified for the selected transaction. These notices 
can be in a variety of electronic formats, and could even include using facsimile or 
postal mail services. Preferably these notices include any total calculated prices and/or 
pricing indications necessary to verify the price levels previously calculated for the 

15 transaction. 

The commerce server 13 either uses appropriate modules to bill the 
buyer, or waits for proof of delivery to occur before the buyer is billed 49. The buyer 
awaits shipment of the goods 51. In response to the advance shipping notice 43, the 
warehouse, the brokers, and all notified freight forwarders and carriers undertake 
20 preparations 53 for their respective service activities. 

Using appropriate modules, the international-trade server 25 transmits a 
message to the warehouse 45 to "pick and pack" 55 the purchased goods for shipment 
to the buyer. The warehouse then packages the goods as necessary, and labels them 
appropriately 57. The warehouse also notifies the international-trade server of the 
25 anticipated shipment date. The laws of the relevant countries, including the countries 
of citizenship for the buyer and seller, might require that additional checks be made for 
restricted transaction parties such as if the shipment date occurs more than a maximum 
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allowable period after the previous restricted party check was made. If an additional 
restricted party check is required, the international-trade server queries the appropriate 
service engines 59, and then sends the appropriate shipment authorization and 
instructions 6 1 or transaction cancellation to the warehouse, the various service-activity 
5 providers, and/or the commerce server. The warehouse, forwarders, and/or carriers 
begin transportation of the goods 63. 

The international-trade server also uses appropriate module to generate 
customs instructions, including a customs invoice, and transmits these customs 
instructions 65 to the appropriate brokering party or parties. Typically this brokering 
10 party will be a customs broker, as discussed above. However, in some cases, actual 
parties to the transaction will act as their own customs broker, as may be required by 
national law. Both situations can occur for a single transaction, as the goods might 
cross a number of international borders. The brokering party or parties broker the 
goods 64 when they reach appropriate customs stations. 

Throughout the process of packaging, transporting, and brokering the 
goods, status updates are generated 7 1 and transmitted to the international-trade server. 
Preferably, status updates are periodically generated by the warehouse, and each 
forwarder, carrier and broker involved in the transaction. In particular, each of the 
service providers notifies the international-trade server when they initially take charge 
of the goods, when they deliver and/or otherwise complete their services, and at any 
relevant checkpoints during their services. 

Using appropriate modules, the international-trade server 25 compiles all 
status updates in a database. Upon receiving a request 73 from the buyer, from the 
commerce server, or from any other relevant party having access rights to the 
25 information, the international-trade server generates a report 75 summarizing or 
describing this status of the shipping and brokering activities. 
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The final status update is a proof of delivery 81. Upon receipt of the 
proof of delivery the international-trade server 25 notifies the commerce server 13 that 
the buyer has received the goods, and that the commerce server is now cleared 83 to 
charge the buyer 85 for the goods if it has not previously done so. 

5 The various service activity providers will preferably transmit invoices 

to the international-trade server based upon their fees and advanced costs. These 
invoices can be generated on a transaction-by-transaction basis, or on a periodic bases. 
International-trade server modules preferably verify that a status update has been 
received indicating that the service activity provider completed their services. If the 

10 status update has been received, then international-trade server modules arrange a 
payment to the activity service provider. Individual payments can be made for each 
transaction, or payments can be summed and paid on a periodic basis. At the same 
time, status reports can be reviewed against performance targets, and a database of 
performance data can be updated, providing for the selection of preferred service 

1 5 providers in the future. Finally, international-trade server modules preferably bill, and 
receive payment from the commerce server (or its operator) either on a transaction-by- 
transaction basis or periodically. 

Throughout the process, the international-trade server and its various 
modules, e.g., service engines and databases, keep transaction histories to provide an 
20 accurate accounting of the transaction. These records are used to provide a variety of 
audit reports and conduct other functions. 

Using appropriate modules, the international-trade server 25 conducts 
certain periodic processes to meet government regulations for its buying and/or selling 
entities. In particular, it compiles export information for each selling entity and 
25 provides it either to that selling entity, or directly to the relevant government. 
Likewise, any governmental reporting of environmental, packaging or other such issues 
is provided. In cases where the goods were originally shipped into the country that they 
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were subsequently exported from, and when the international-trade server was either 
involved in that importing operation or was later notified of it, then the international- 
trade server compiles the information and assists the appropriate entity in applying for 
duty drawbacks, either in actual refunds or duty credits. It also provides transaction 
5 summaries and reports to meet any national compliance regulations and/or audits that 
the parties might be required to undertake. 

Online Purchase of Manufactured-On-Demand Product 

The invention is also embodied in a process for purchasing products 
manufactured at the request of a buyer. The architecture of a system to implement this 
10 process can be similar to one designed to provide for the process described above. It 
can even use many of the same application servers and modules, i.e., service engines 
and databases. 

In this process, the customer participates in an e-commerce purchasing 
activity, using a web-server environment, a dedicated client-server environment or a 
15 non-interactive e-commerce software (e.g., inventory replenishment software). The 
buyer could be quoted a fixed price based on previous experience, or a price could be 
calculated using methods related to those described above. 

Prior to a price being calculated, a procurement application server sends 
messages to suppliers, who respond with their bid of cost and time to provide parts for 

20 the goods to be manufactured. Likewise, messages are sent to contract manufactures, 
who respond with their bid of cost and time to provide manufacturing services. 
Additionally, the TLCL service engines of an international-trade server, as described 
above, are used to calculate the cost and time figures for the various scenarios of 
transporting goods (both parts and/or final products) so as to provide for the 

25 manufacture and delivery of the ordered final products. 
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All these costs are aggregated, providing an accurate total cost and 
delivery time for the buyer to purchase the goods. As in the first described 
embodiment, the buyer (or its software) then chooses from among the manufacturing 
and transportation options and orders the goods. While payment could be delayed until 
5 the buyer receives the goods, preferably the buyer arranges payment upon ordering the 
goods, as they are being manufactured at the buyer's instruction. 

In a manner similar to the procedure described above, the system notifies 
all part and service providers that their bids have been accepted. The system authorizes 
and manages manufacturing and delivery through a series of instructions and status 
10 checks. 

In the case where a fixed price was quoted upon order, the price being 
based on past experience and/or previous contractual commitments, the bidding for 
parts and manufacture is conducted after the order is placed. The seller then selects the 
part suppliers and manufacturers based on the total cost of the final products, including 
15 all costs associated with the international trade issues that occur during manufacture 
and delivery. 

In cases where the buying entity provides parts across country borders 
to the selling entity for the manufacture of the goods, various options are available to 
the buyer to properly pay the duties on the re-import of the provided parts. This is 
20 called an "assist." When the international-trade server actually conducts the 
transactions, it tracks the parts, and uses the information (under the buyer's preferred 
"assist" accounting methods) in generating customs documents for the importation of 
the goods into the buyer's destination country. 


TLCL SYSTEM ARCHITECTURE 
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Typical embodiments of the present invention also reside in a network 
architecture, in computer systems (such as an international-trade server), and in related 
software, configured for handling international trade. A preferred embodiment of the 
invention is configured for handling business tax, license (export administration), 
5 customs and/or logistics (TLCL) issues in the import/export of goods across 
international borders. This preferred embodiment of the invention resides in a system 
to link and direct certain electronic communication between buyers, sellers, customs 
brokers, shippers, other service providers, with information and services from various 
computer software service engines, which can be operated and maintained by a variety 
10 of entities, that are not designed to be integrated with each other. Additionally, 
preferred embodiments of the invention reside in the computer system and related 
software and business methods recited above, when combined with the service engines 
to form a networked system for guiding a user through the TLCL issues raised by a 
business transaction spanning one or more international borders. 

1 5 Typically, embodiments of this invention integrate a full range of TLCL 

applications, providing distinct business functions, into a single seamless set of 
services. This integration provides synergies that are not typically available to 
inexperienced customers. Because the technology includes intelligence in the front 
end, users can operate the software without having expertise in TLCL issues. This 

20 allows a corporation to operate import/export operations legally, efficiently, cost- 
effectively, and consistently, while allowing individual business people to conduct their 
own transactions (i.e., without surrendering complete control to a centralized 
department disconnected from the needs and business practices of the individual 
customers). 

25 CUSTOMERS 

With reference to FIG. 2, the TLCL system is configured to assist and 
guide both buyers and sellers, which will jointly be referred to as Customers 101, 
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through the range of TLCL issues that they face in cross-border transactions. To be a 
user of the TLCL system, the Customers will typically access a local computer having 
a browser 103. That Customer and their computer are placed in interactive 
communication with the TLCL system, preferably through a user interface such as a 
5 web portal 105, via a data communications network such as the Internet 107. These 
communications channels (denoted as interactive by an "I" in FIG. 2) are used for 
interactive communication between a customer and the TLCL system. 

Customers 101 also might possess other computers placed in 
communication with the TLCL system. In particular, Customers may have local 

10 information systems 109 that communicate with the TLCL system, either via a 
communications network such as the Internet using various standard communications 
protocols, or via direct communication lines established with the TLCL system. These 
communications channels (denoted as being for data transfer by a "D" in FIG. 2) are 
used for low level, computer to computer data transfer that does not involve a Customer 

1 5 interactively participating in the transfer. These interactions can be request-and-reply- 
type communications or data objects (i.e., messages communicating events). The 
customer-based information systems might conduct many different functions relating 
to ordering, accounting, and various TLCL issues. Preferably the customer-based 
information systems will directly communicate with a computer system serving as an 

20 external message broker 111 for the TLCL system. 

Large corporate clients of the TLCL system can contain many individual 
TLCL-system Customers 101 spread across many countries. For example, within an 
international conglomerate, there can be many thousands of purchasers and sellers that 
operate separately and distinctly from each other, each having their own information 
25 systems 109 and their own purchasing and selling procedures. 

In addition to the above facilities, Customers 101 will likely have 
facsimile machines and other communications devices that provide for information 
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sharing. Because there is a myriad of possible Customers, there will be a wide variety 
of different communication capabilities among the Customers, even within the same 
corporate client of the TLCL system. Some Customers might not have information 
systems configured to interact with the TLCL system, some might not have browsers, 
5 and some might have little to work with other than a telephone. 

Customers 101 will have varying levels of knowledge about the myriad 
of TLCL requirements that international transactions must meet. Some Customers will 
have significant experience with transactions across many regions of the world, and 
will be at least somewhat familiar with many countries' TLCL requirements. Other 
10 Customers will have experience within a certain region, such as the countries of the 
European Union, but will have little knowledge of the TLCL requirements of countries 
outside their region of expertise. Finally, some Customers will have little to no 
experience with TLCL issues at all. 

SERVICE ACTIVITY PROVIDERS 

The import/export industry includes a large number of providers of 
service activities to assist buyers and/or sellers in conducting international trade. These 
providers, which shall be referred to as Service Activity Providers 113, include customs 
brokers, forwarders, carriers, and free-trade zone managers. For example, in countries 
where it is legal, customs brokers typically act as the buyer's agent (or possibly the 
seller's agent) with the local customs service. Carriers physically transport the goods, 
via plane, truck, train, boat or otherwise, and forwarders coordinate carriers for 
complex shipping needs. Free-trade zone managers operate free-trade zones in 
countries such as the United States, where they are legal. 

Like the Customers 101, the Service Activity Providers 1 1 3 will interact 
25 with the TLCL system as users, preferably using interactive and data communications 
means (denoted by an "I" and "D", respectively, in FIG. 2). For an interactive 
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communication means, the Service Activity Providers can use a local computer having 
a browser 115. That computer is placed in interactive communication with the TLCL 
system, preferably through the web portal 105, via a data communications network 
such as the Internet 107. 

For a data communication means, Service Activity Providers 113 are 
likely to use computers that assist in conducting their business activities, such as for 
generating documents, tracking shipments, scheduling activities, and the like. These 
computers are placed in communication with the TLCL system to communicate 
relevant data. In particular, Service Activity Providers may have local information 
systems 117 that communicate with the TLCL system via a means of communicating 
data, such as direct communication lines established with the TLCL system or a 
communications network like the Internet. Preferably the local information systems 
will communicate with the external message broker 111 for the TLCL system. 

Similar to the Customers 101, the Service Activity Providers 113 will 
likely have facsimile machines and other non-interactive communications devices that 
provide for information sharing. Because there are a large number of Service Activity 
Providers, there are a wide variety of different communication capabilities among the 
Service Activity Providers. Some might not have information systems 117 configured 
to interact with the TLCL system, some might not have browsers 115, and in some 
portions of the world, some might be very isolated (e.g., a local transportation company 
in a remote third world location might be very limited in communication facilities). 

Service Activity Providers 113 will often be expert in their field and/or 
their local market. However, they will not often be well acquainted with the 
Customers' goods and the legal concerns raised by those goods. 
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The TLCL system is generally under the control and/or direction of a 
TLCL System Provider that owns and operates the TLCL system. The TLCL System 
Provider can be an entity that requires the TLCL services for its own purposes, such as 
5 an international conglomerate that has large numbers of buyers and/or sellers 
conducting international business transactions. Alternatively, the TLCL System 
Provider can be an entity who's primary business is the provision of services to 
companies that requires the TLCL services. Of course the TLCL System Provider 
potentially can fill both of the above-mentioned roles. Preferably, the TLCL System 
1 0 Provider can access the TLCL system both via access to the TLCL system computers, 
and indirectly via a browser in the same manner as a Customer 1 0 1 or Service Activity 
Provider 1 13. 

Typical embodiments of the TLCL system will include a network of 
computer hardware and software, characterized by an architecture defining a firewall 

15 123, the web portal 105, and an application management system including an 
application server 125, which could also be referred to as a process server, and a 
service engine communication layer 127. A variety of TLCL services are integrated 
and provided through the use of a plurality of service engines. Included among these 
are one or more internal service engines that are within the firewall, and one or more 

20 external service engines outside the firewall. Some data used by the service engines, 
such as government regulations, classifications and restricted parties, are kept up-to- 
date via data communications with information sources 129. 

Strictly interactive internal service engines 131 are configured for only 
interactive, real-time processing of TLCL issues for Customers 101 or Service Activity 
25 Providers 113, while mixed interactive internal service engines 1 33 are configured for 
both interactive processing and data-type processing in response to the receipt of 
requests and/or data objects representing various relevant queries and/or events. 
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Likewise, strictly interactive external service engines 135 are configured for only 
interactive, real-time processing of TLCL issues for Customers 101 or Service Activity 
Providers 113, while mixed interactive external service engines 137 are configured for 
both interactive processing and data-type processing in response to the receipt of 
5 requests and/or data objects representing various relevant queries and/or events. 
Internal or external devices that only conduct data-type processing in response to the 
receipt of requests representing various relevant queries are referred to as internal 
reference servers 139 and external reference servers 141, respectively. However, while 
these devices typically serve in a database capacity, they might conduct some 
10 processing to meet the requirements of some queries. 

Interactive Processing Communications 

Each service engine configured for interactive processing is in interactive 
communication with the service engine communication layer 127 of the application 
management system via an interactive connection (denoted as interactive by an "I" in 
15 FIG. 2). The service engine communication layer provides translation facilities for 
communication with the wide variety of communication protocols that might be used 
by the service engines. 

In particular, each internal service engine 131 and 133 is linked to the 
service engine communication layer 127 via an internal interactive connection (denoted 

20 as interactive by an "I" in FIG. 2) configured for communicating interactive 
information. Each external service engine 135 and 137 is preferably linked to a router 
151 via an external interactive connection (denoted as interactive by an "I" in FIG. 2) 
configured for communicating interactive information. The router has an interactive 
communications link (denoted as interactive by an "I" in FIG. 2) placing it in 

25 communication with the service engine communication layer. The router preferably 
spans the firewall 123, providing for a single "hole" in the firewall to support all 
interactive communications between the service engine communication layer and all 
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or most of the external service engines. Optionally, some external service engines 
could be in communication with the service engine communication layer through 
separate holes in the firewall that are not maintained by the service engine 
communication layer and the router. The service engine communication layer can be 
5 considered a layer of the application server rather than a separate module. 

Within the application management system, the service engine 
communication layer 127 is linked in communication with the application server 125, 
which directs, buffers and processes the various communications between the users and 
the service engines 131, 133, 135 and 137. The application management system 
10 communicates with the users via the web portal 105. 

The firewall, 123, the web portal 105 and the application server 125 each 
provide authentication and security tasks for verification of the users' interactive usage 
rights in the TLCL system. In particular, the firewall includes a web agent that limits 
web portal access to verified users, thus serving as a gatekeeper to the web portal. The 
1 5 web portal 1 05 also includes a web agent that limits the general types of tasks that each 
user is allowed to conduct. Finally, the application server, which governs the operation 
of the service engines, limits access to the particular sub-functions and information for 
which the user has approved access. 

For example, when a customs broker accesses the TLCL system using its 
20 browser 1 1 5, the firewall web agent verifies that the customs broker is within the group 
of approved users, and then allows the customs broker access to the web portal. At the 
web portal, the customs broker is provided a set of TLCL operations to which the 
customs broker has access. The extent of that set of options is governed by the web 
agent of the web portal 105. After the customs broker selects a function, such as 
25 customs invoice generation, the application server 125 leads the customs broker 
through a series of interactions with a series of service engines. The application server 
web agent controls the customs broker's access to the individual functions within each 
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service engine, based on the customs broker's approved access. The application server 
web agent further controls the customs broker's access, limiting it to data that the 
customs broker is allowed to access. Thus, security and authentication over interactive 
communications are conducted in three levels. 

5 Data-Type Communications 

Each service engine configured for data-type processing is interconnected 
via connections configured for communicating requests and replies (e.g., database 
queries and related processing), and/or data objects. These data connections are 
denoted as being for data transfer by a "D" in FIG. 2. Depending on the type of data 
10 transfer, data-type communications are conducted either via a gate-keeping message 
broker or the service engine communication layer 127. 

The gate-keeping message broker includes an internal message broker 
161 and the external message broker 111. These two portions of the gate-keeping 
message broker are linked via a data-type communications link 163 passing through a 

15 hole in the firewall 123. The internal message broker is in data-type communication 
with both the internal reference servers 139 and the internal service engines 133 
configured for data processing in response to the receipt of requests and/or data objects 
representing various relevant queries and/or events. Likewise, the external message 
broker 1 1 1 is in data-type communication with both the external reference servers 141 

20 and the external service engines 137 configured for data processing in response to the 
receipt of requests and/or data objects representing various relevant queries and/or 
events. Through the gate-keeping message broker, these entities can be kept in data- 
type communications. Optionally, some external service engines could be in 
communication with the internal message broker or with internal service engines 

25 through separate holes in the firewall that are not managed by the router. 
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To direct particular queries to which a service engine requires a reply, 
such a query is sent by the requesting service engine to the portion of the gate-keeping 
message broker on the same side of the firewall as the requesting service engine. The 
gate-keeping message broker then directs the query to the appropriate, replying service 
5 engine or reference server to reply to the request. If the replying service engine or 
reference server is on the opposite side of the firewall from the requesting service 
engine, then the request is appropriately passed between the internal and external 
broker portions of the gate-keeping message broker. Similarly, when the reply is 
generated by the replying service engine or reference server, it is sent to the portion of 
1 0 the gate-keeping message broker on the same side of the firewall as the replying service 
engine or reference server, and then directed to the requesting service engine, passing 
through the firewall via the gate-keeping message broker if necessary. 

An event (i.e., a data object representing relevant activity) can be 
generated in several ways. First, a TLCL system user can interactively initiate an event 
15 by entering the data via the web portal. Second, a TLCL system user can use a local 
information system 109 or 1 17 to generate an event that is then passed to the external 
message broker 111. Finally, a service engine that is operating on an existing event can 
generate data that serves as the basis for further events. 

In each of these cases, the event data are either generated in, or 
20 communicated to, the application server 125. Events passed to the external message 
broker are communicated through the firewall to the internal message broker, and then 
on directly to the process server via a data-type communications link. Event data 
generated within a service engine, be it internal or external, are communicated to the 
service engine communication layer 127, which then communicates the event to the 
25 process server. The data-type communications link between the service engines and 
the service engine communication layer can optionally be the same communications 
link used for interactive communication (as depicted in FIG. 2), or a different link. 
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Once the application server receives the event data, it directs the 
processing of the event through various service engines, as appropriate. The 
application server selects the appropriate service engines based upon the source of the 
data, the type of event that the data represents (e.g., a financial invoice, a status update 
on a shipment or a notification received from a particular country's customs service) 
and/or the content of the data (e.g., the exporting and importing countries, the 
nationalities and/or identities of the buyer and seller, the classification and type of 
goods, the value of the goods and the toxic or environmental relevance of the goods). 
In the subsequent processing of the event, additional events and queries can be 
generated. 

The information sources 1 29, which are typically governmental or private 
entities outside the firewall 123, are also linked in communication with the external 
message broker 111 via connections configured for communicating data objects 
(denoted as being for data transfer by a "D" in FIG. 2). In some cases, they can 
generate events such as update notifications, sending those events to the application 
server via the external and internal message brokers. Additionally, service engines 
and/or reference servers can query the information sources for information. 

The application server 125 and service engine communication layer 127 
provide authentication and security for verification of each service engine's usage 
rights in the TLCL system with relation to a given event. In particular, the application 
server, which governs the operation of the service engines, controls the selection of 
service engines that receive an event. The service engine communication layer then 
polices the events passed from one service engine to another in comport with the 
dictates of the application server. 
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TLCL System Functionality 

A user of the TLCL system, such as a Customer 101, a Service Activity 
Provider 1 13, or the TLCL System Provider, can access the functionality of the TLCL 
System by contacting the web portal 105 via a web browser over the Internet 107, an 
5 intranet, or another network connection. The user's interactive communications to the 
TLCL system are preferably configured for World Wide Web-based protocols, such as 
are used by systems operating in HTML (Hypertext Markup Language), XML 
(Extensible Markup Language), XSL (Extensible Stylesheet Language), Java, JSP 
(JavaServer Pages) and Epicentric. 

10 As described above, the user's communications are passed via the web 

browser 105 through the firewall 123, and are screened for various levels of access 
rights by the firewall 123, the web portal 105 and the application server 125. 

The application server 125, typically developed in an appropriate 
middleware such as bluestone products or Enterprise Java Beans, is preferably 

1 5 configured to seamlessly guide a user through the processes that are relevant to them. 
In particular, it is configured to guide a Customer 101 through import/export related 
processes, to guide a Service Activity Provider 113 through their relevant import/export 
related activities, and to guide any user through any authorized reporting, auditing, 
and/or accounting procedures. Preferably, after the user selects the activity that the 

20 user requires, the application server both guides the user into and through each relevant 
service engine, and buffers their interaction with each service engine to provide a 
consistent, user-friendly interface that characterized by a consistent look and feel, 
consistent terminology and easy-to-understand instructions. In doing so, the 
application server preferably accesses information on the various TLCL requirements 

25 of different countries and different users, to selectively activate the service engines (and 
portions of service engines) most appropriate to the user's needs. 
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The service engines and reference servers are configured to pass and store 
data such that each function is provided related data from other functions to simplify 
the user's experience. For example, upon the classification of goods, the application 
server might direct the user through a process that verified whether the goods raise 
5 legal issues regarding toxicity. 

A user of the TLCL system, such as a Customer 101, a Service Activity 
Provider 1 13, or the TLCL System Provider, can also access the functionality of the 
TLCL System by passing data objects directly from an information system to the 
external message broker 1 1 1, or even to the internal message broker 161 if a separate 
10 hole is maintained in the firewall. The external and/or internal message brokers rout 
the data object to the application server 125, which then directs the appropriate service 
engines to process the event. 

i 

i 

In their operations, the service engines might also take data and/or 
instruction from each other or from other software packages, typically receiving 

15 information in data-type objects. For example, when a customer first conducts a 
transaction, they may use local ordering processing software that generates financial- 
invoice-type data obj ects in their local information systems 1 09 . These data obj ects can 
be transmitted via the external message broker 111 and/or internal message broker 161 
to the application server, which forwards the objects to appropriate service engines, 

20 where the data is used to initiate and instruct certain processes. One such process could 
be the generation of a customs invoice from the financial-invoice-type data, and the 
transmission of the customs invoice to an appropriate broker using whatever 
communications technology that the broker is known to use. The process could also 
include selecting a broker based on past performance criteria stored in the system. 

25 Other related processes would be one to monitor the broker's performance when the 
broker reports its status, and add that performance data to a database of past broker 
performance. 
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The service engines will frequently include or rely upon extensive 
databases and lookup tables reflecting the current requirements based on the countries 
of shipping origin, shipping destination, and intermediary travel, as well as the 
countries of the Buyer's and/or Sellers citizenship. Included among these are various 
5 national and international rules and regulations, import and/or export licensing 
requirements, duty rates, classification codes, and other customs limitations, such as for 
toxic substances, packing materials, restricted parties and countries, auditing 
requirements, and the like. 

The many governments of the world have a variety of such TLCL 
10 requirements in the form of import laws, regulations, rules, best practices and the like 
to deal with these subjects. These TLCL requirements change frequently. Whether it 
is a governmental agency or a private information service, the Information Source 
offers access to up-to-date information to computer systems, providing compilations 
of this information and/or frequently updated lists of TLCL requirement changes. 
1 5 These Information Sources can also be provided within components of the information 
systems operated by Customers, Application Service Providers and/or Service Activity 
Providers. 

For the service engines, the external message broker 111 could serve as 
a gateway for updating the database information on a periodic and/or selected basis. 

20 For the internal service engines 131 and 133, the internal message broker 161 is also 
part of that gateway. Thus, at periodic intervals, at the instruction of the TLCL System 
Provider, upon receiving an update notification from an information source, or possibly 
at the request of a user, the service engine and the information source interact to 
updates the data contained in the service engine. The internal and external service 

25 engines can alternatively be updated through other forms of communication. This is 
particularly true for service engines that are not owned, operated or directed by the 
TLCL System Provider. 


10011098-1 

33 

Service Engines 

The application management system is preferably configured to work 
with a plurality of internal service engines 131 and 133 and a plurality of external 
service engines 135 and 137. Each service engine is configured to provide one or more 
5 services relating to one or more TLCL issues that arise in international import and/or 
export business transactions. Most service engines are configured either to run 
autonomously or to interact with a limited set of other service engines and/or 
information servers to accomplish a limited task or set of tasks. 

Some service engines may be designed and written by (or under the 
10 direction of) the TLCL System Provider. Such service engines are generally operated 
within the firewall by employees or contractors of the TLCL System Provider. Other 
service engines might be applications written and owned by outside software 
developers, but that are significantly altered and/or configured to meet the functional 
needs and/or the connection requirements of the TLCL system. These service engines 
15 could readily be either inside or outside the firewall, most likely depending upon the 
party that operates the service engine. 

Finally, some service engines are likely to be applications that are entirely 
owned and operated by outside entities. These entities could be Application Service 
Providers having expertise in some segment of the import/export industry, or even 
20 Customers 1 0 1 or Service Activity Providers 113 who are selling their information and 
expertise for additional profit. Therefore, while the external service engines 135 and 
137 are depicted separately, it should be understood that they could reside in the 
information systems of the Customers or Service Activity Providers. 

It typically is highly beneficial to use the service engines of Service 
25 Engine Operators such as Application Service Providers, Service Activity Providers 
and/or Customers that have significant import/export experience. These Service 
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Engine Operators can have significant expertise in their particular services and/or 
localities of operation. Additionally, these Service Engine Operators might have 
existing business relationships, computer connections and/or information sources that 
are highly beneficial to the Customers. Indeed, it is unlikely that a single company will 
5 produce the best-of-breed software either for every TLCL function or in every legal 
jurisdiction. Included among the external service engines that might be accessed are 
tax calculation engines, logistics information and negotiations, goods classification 
engines, and repositories to track transactions. 

Because different engines might be preferable depending on the exporting 
country, the importing country, the nationality of the buyer, the nationality of the seller, 
and even other issues such as the nature of the goods, there might be numerous service 
engines having similar functionality within the TLCL system. For example, one 
service engine might be used for import regulations in Europe, while another is used 
for import regulations in the United States. Furthermore, since service engines might 
include an integration of several functions, each having varying levels of desirability, 
it is very possible that the system will use one function out of a particular integrated 
service engine, while not using another (or only using the other for specific jobs). 
Additionally, the TLCL system could include service engines intended for use if other 
service engines are overloaded or suddenly unavailable. This would provide 
redundancy and thereby increase reliability. 

In some cases, Service Engine Operators might have developed service 
engines tailored to their individual needs. For example, departments within large 
TLCL clients might have developed software service engines configured to deal with 
TLCL issues that relate to issues relatively specific to the client's products, to the 
25 Client's locality, or the Client's other software systems (such as accounting systems). 
Likewise, Service Activity Providers might have service engines that primarily meet 
their own processing needs based on their own internal procedures. For example, a 
freight carrier might have logistics software configured to estimate its own shipping 
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costs and track shipments through various stages of transportation. Likewise, a 
customs broker might have customs software configured such that, given the financial 
invoices that are in transit with purchased goods, the brokers can print out customs 
invoices formatted it the manner in which that broker chooses to operate. 

5 SERVICE ENGINE FUNCTIONS 

The service engines can be configured to do a wide variety of functions. 
Some of these functions are interactive, and some relate to the use, manipulation, 
processing, storage, archiving, and reporting of data. The preferred embodiment 
preferably includes service engines configured to form five integrated, primary- 
10 function engines: a tax engine, an export engine, an import engine, a logistics engine 
and a payment engine. The preferred embodiment also includes service engines 
configured to provide customer management and reporting. Other embodiments could 
include additional functional engines, such as ones to assist in making legal decisions 
or manage financial transactions for international trade. 

1 5 Tax Engine 

The tax functional engine comprises one or more service engines that 
provide information, assist in reporting and/or assist in paying various taxes relating 
to transactions in jurisdictions around the world. Related databases include a database 
of tax rates for each tax jurisdiction, as well as any product classification information 
20 necessary to assess the correct tax rates. 

Preferably, buyers and/or sellers can access the tax engine to determine 
the tax-cost of each potential transaction. This can be particularly important for large 
entities, which can ship or receive goods in any of a number of different countries. The 
savings resulting from selecting optimal shipping sources and destinations can be quite 
25 substantial. Such a calculation will generally need to consider the variation in other 
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costs such as shipping, customs, and related support (e.g., brokering). These other 
costs are preferably available through other engines, as described below. 

The tax functional engine also can serve as a repository for tax payment 
information. This provides both for the correct payments of transaction tax, and for the 
5 efficient reporting of transaction tax payments to the financial entities that calculate and 
pay regular corporate taxes. 

Export Engine 

The export functional engine includes service engines each having 
functionality to take care of export issues in one or more jurisdictions. One typically 

10 important export issue is the tracking and reporting of export transactions to meet the 
governmental summary reporting requirements of most countries. Also included are 
warnings against export limitations that various countries might have. For example, 
exports from the United States, and shipments by US entities (regardless of the export 
locations), are subject to restrictions on parties and/or countries that can receive the 

15 goods. Likewise, certain technologies and substances are restricted. 

While many exports are not limited, licenses are required for exporting 
various goods from many countries. The export engine is preferably configured with 
service engines that verify a client has the proper export licences, and that act to apply 
for needed licenses. In any countries where such applications can be done 
20 electronically, the actions are preferably taken directly by the service engines. In other 
countries, the service engine preferably communicates with appropriate staff (at the 
Client, the TLCL System Provider, or an outside vender of such services), directing 
them to apply for the appropriate license. In either case, the service engine also acts 
or otherwise flags the export so that it is delayed until it is properly licensed. 
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Related databases accessed by the service engines of the export functional 
engine preferably include a database of the export reporting requirements of each 
jurisdiction, a database of the laws regarding restricted parties and countries with which 
to do business, a database of the licensing requirements of each jurisdiction, a database 
5 of the licenses actually held by the clients, and any product classification information 
necessary to assess the licenses needed for any given transaction. 

The export functional engine also can serve as a repository for export 
information used in the re-importation of components within larger products, i.e., the 
export of goods by a first party to a manufacturer that will take the goods and 
10 incorporate them into products to be sold back to the first party. This activity is 
referred to as an assist. Various import options exist for claiming an assist, and 
preferably the service engines of the import functional engine can access both the 
export engine (or its records) and the client's customs preferences to determine what 
types of assist claims will be made. 

15 Additionally, the export functional checks a repository for import 

information for indications that the exported goods were previously imported and that 
duties were previously paid. For such cases, the export engine activates service engines 
to arrange for drawbacks (i.e., a refund of the duties that were previously paid). In 
some countries this will entail a shipment-by-shipment application, while in others it 

20 will entail the entering of a database entry, along with a summary application being 
generated periodically. 

Import Engine 

The import functional engine includes service engines having 
functionality to take care of import issues in one or more jurisdictions. One typically 
25 important import issue is the handling of imported goods through customs, whether by 
the client themselves or a third party customs broker. Central to the import process is 
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the proper description and classification of goods. Also, of high importance are the 
consistent description and classification of goods. These are both important for legal 
compliance with import laws in most jurisdictions. Additionally, duties need to be 
calculated, paid, tracked and reported for corporate financial considerations. Also, 
5 various formats and preferred business practices should be adhered to, depending on 
the jurisdiction. 

To manage these issues effectively, the import functional engine 
preferably includes one or more service engines that generate, or assist in the 
generation of, customs invoices that consistently and accurately describe the products. 
Preferably these service engines take into account both the best practices and the legal 
requirements of each country, as well as prior rulings by each country on each client's 
goods. The service engines also preferably account for any assists that are to be 
claimed during import, such as is described above with regard to the export functional 
engine. The service engines deliver the customs invoice information to the appropriate 
broker or company representative in the import jurisdiction in a timely fashion, 
preferably prior to the arrival of the goods to minimize the time spent in customs. Also, 
a service engine records the transaction such that the export engine can access the 
information and check for potential drawbacks. 

More particularly, the service engine is a server configured to receive a 
20 billing file, to read and parse the billing file, to organize each billing file according to 
a particular category, i.e., ship to country, and to create customs invoices for a 
particular country using information contained in the billing file. Once the billing file 
is received, the server is configured to adjust the value of the goods based on the 
discount code. The server uses the country code to determine the format of the customs 
25 invoice from the tables, e.g., customs invoice configuration tables, managed in the 
server. Information pertaining to each country is input into tables contained in the 
server. Further, the server is configured to group the products from the billing file into 
a list sorted by product number and country code, and to delete duplicate product 
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numbers from the list. Using the product number and the country code as the query, 
the server makes a call to the product regulatory reference server, which returns a 
classification number, i.e., a local HTS number, for the product, an export control 
commodity number (ECCN), and an acceptable description of the goods. Each product 
5 number has a unique ECCN. The local HTS number, the ECCN, and the acceptable 
description of the goods are returned and incorporated into the billing file. The server 
creates a customs invoice for the particular country using the billing file and creates an 
encrypted electronic file of the customs invoice. The server also creates an envelope 
containing the encrypted electronic file and serializes the envelope. The encrypted 

10 electronic file is stored in the database and the envelope is transmitted via email to an 
email address that is accessed by the customs broker. To obtain the email address, the 
server retrieves the consignee code from the billing file, finds the consignee code in one 
of the tables, and retrieves the corresponding email address, which is stored in the same 
table. All customs invoices having the same consignee code are sent to the email 

15 address. There can be multiple email addresses assigned to each consignee code. 

To the extent possible, a customer can use the import functional engine 
to query a broker status of the import operation, and to study the history of performance 
by various brokers when selecting a broker to use. Alternatively, the functional service 
engine can select a broker based on its cost and history of performance. 

20 Additionally, some countries include various limitations on the products 

and packaging that can be imported. These limitations can be trade limitations on 
products that have been imposed by certain governments. They can also be health, 
safety or environmental limitations, such as relating to dangerous substances, protected 
species, or pollution/recycling requirements on products and/or packaging. They can 

25 even be restricted parties or countries for trade, which was already discussed above 
with regard to the export engine. 
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The import engine is preferably configured with service engines that 
verify that the goods, the packaging, the trading partners and the exporting countries 
all are proper under the importing country's laws. In cases where significant issues 
arise that cannot be handled by the service engines, the system notifies specialists (at 
5 the Client, the TLCL System Provider, or an outside vender of such services) that 
action must be taken. 

Related databases accessed by the service engines of the import 
functional engine preferably include a database of the acceptable product descriptions 
and classifications for each jurisdiction, a database of the customs rules, best practices 

10 and procedures of each jurisdiction, a database of the import restrictions and health 
/safety/environmental requirements of each jurisdiction, and a database of the product 
types of each client, along with prior rulings governing their classification in various 
jurisdictions. Also, a repository of import information, including duties paid, time in 
customs, and parties managing the customs operation, is preferably maintained. This 

1 5 repository is used both for various financial considerations and for the analysis of the 
performance of customs brokers and/or related parties. 

Logistics Engine 

The logistics functional engine includes service engines having 
functionality to manage logistics issues through various jurisdictions. Related 

20 databases accessed by the service engines of the logistics functional engine preferably 
include a database of freight forwarders and carriers serving various types of cargo in 
various markets, along with their rates and any discounts that can be had due to 
connections with the Buyer, the Seller, the TLCL System Provider, or other related 
parties or factors. Also, included can be a database of historic information on various 

25 performance factors of the carriers. 
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Preferably, buyers and/or sellers can access the logistics engine to 
determine the cost efficient course of shipping, considering the available forwarders 
and/or carriers, considering the various discounts that have been arranged due to 
business arrangements with the forwarders and/or carriers, and considering the history 
5 of on-time and safe delivery of cargo by each forwarder and/or carrier. To the extent 
possible based on forwarder/carrier arrangements, a customer can use the logistics 
functional engine to arrange shipments, and to query the forwarder/carrier for location 
and status information on the shipments. 

The logistics functional engine also can serve as a repository for historic 
10 logistics information. This provides both for the analysis of carrier performance and 
the selection of preferred carriers. 

Payment Engine 

The payment functional engine includes service engines having 
functionality to manage payments (i.e., to instruct payment entities regarding payments, 

15 or to initiate electronic payments) made to outside vendors and/or governmental 
agencies for the various fees and services incurred in the TLCL portion of a business 
transaction that results in the international shipment of goods. Included among these 
payments can be customs brokers' fees, freight forwarders' fees, carriers' fees, other 
Service Activity Providers' fees (including any fees due to the TLCL System Provider), 

20 fees to related providers of information or electronic services, and duties. Related 
databases accessed by the service engines of the payment functional engine include any 
needed to identify costs related to the above types of payment. Also included can be 
a database of historic information on various payments actually made for various 
accounting purposes. 
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Additional details on some service engines of the present invention are 
contained in the following applications, which were incorporated by reference into the 
parent application of the present application. 
5 1) PCT patent application, entitled "Methods of Creating Electronic Customs 
Invoices", Serial No. USO 1/30696, filed in the US Receiving Office on October 1, 
2001, under the attorney docket number 10012294-1, which is hereby incorporated 
herein by reference for all purposes. 

2) PCT patent application, entitled "Order Fulfillment Architecture Having An 
10 Electronic Customs Invoice System", Serial No. US01/30687, filed in the US 

Receiving Office on October 1, 2001, under the attorney docket number 10012299-1, 
which is hereby incorporated herein by reference for all purposes. 

3) PCT patent application, entitled "Regulatory Classification System", Serial 
No. US01/30702, filed in the US Receiving Office on October 1, 2001, under the 

1 5 attorney docket number 1 0002302- 1 , which is hereby incorporated herein by reference 
for all purposes. 

4) PCT patent application, entitled "Export License Determination Server", Serial 
No. USO 1/30746, filed in the US Receiving Office on October 1, 2001, under the 
attorney docket number 1 0002306- 1 , which is hereby incorporated herein by reference 

20 for all purposes. 

5) PCT patent application, entitled "Transaction Monitoring System", Serial 
No. USO 1/30747, filed in the US Receiving Office on October 1, 2001, under the 
attorney docket number 1 0002307- 1 , which is hereby incorporated herein by reference 
for all purposes. 

25 These five applications add further detail and scope to preferred 

embodiments the present invention, and are considered an integral part thereof They 
also provide examples of the interaction of service engines under the present invention. 
For example, the service engine that generates a customs invoice, such as from 
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financial invoice information, makes extensive use of the Regulatory Classification 
System. Additionally, the transaction being handled by these two service engines 
would need to have export license approval, and thus the Export License Determination 
Server would likely operate on related messages for the transaction as well. The 
5 operation and communication of these service engines, and the other service engines 
with which they interact, define patentable systems and methods, and are within the 
anticipated scope of the invention. 

MESSAGE BROKERS 

The internal and external message brokers, 161 and 111, respectively, 
10 work in conjunction as a gate-keeping message broker to facilitate data 
communications between the application server 1 25, service engines (both internal and 
external), reference servers 139, information sources 129, Service Activity Provider 
information systems 117, and other Customer information systems 109. When 
managing the data objects, the message brokers preferably provide a number of relevant 
15 functions. 

First, each message broker preferably includes a variety of different 
interconnect technologies, at least one of which is configured to interconnect and 
receive data communications from each service engine, internal reference server, 
information source and/or information system to which that message broker will 
20 connect. The data can be in a wide variety of formats, such as a flat file record, an 
electronic data interchange ("EDI") of structured data according to agreed message 
standards between computer systems, a spreadsheet entry, extensible markup language 
("XML") or web data. The message brokers will preferably have a standard 
communication format that is efficient for processing large amounts of data. 

25 One or more message brokers also preferably include routers 

programmed with routing logic. The routing logic will preferably be based on the 
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substantive data type (e.g., financial invoice data or updated governmental 
requirements) and the source of the data received. This allows for updating the data 
routing via changes to tables in the message brokers without reprogramming various 
service engines, information sources, and the like. Data objects received by the 
5 message brokers from some or all sources could include supplemental routing 
information, either to supplement internal routing logic, or to override it. Alternatively, 
the message brokers could be configured for all routing information to be included with 
each type of data object. 

In addition, one or more message brokers are preferably programmed to 
10 include data editing and verification checking modules, extending them beyond the 
traditional roles of a message broker. Such modules would preferably include data 
format and/or substantive data checking information for various types of data. These 
modules would preferably use substantive logic based on the data type, and would 
verify the logical correspondence of data within a data object. Upon finding 
1 5 questionable, or faulty data, the quality checking modules could reject the data back to 
its source, correct the data and/or direct the data to experts that can research and correct 
the issues in the data. 

Because the message brokers are configured to work with a wide variety 
of data formats, the message brokers are preferably configured with data translation 
20 modules. These modules would provide the needed translation to place the data into 
each format required by each destination for the data. Given that data can be directed 
to a variety of destinations, it is possible that it will have to be translated into a variety 
of formats. 

As an additional note, while the external and internal message brokers are 
25 depicted as a single entity, other configurations are within the scope of the invention. 
For example, two or more external message brokers could be interlinked, each having 
additional links to a different set of service engines, information sources, reference 
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servers and/or information systems. Thus, competing providers of external message 
broker services could join forces to avoid creating redundant connections. Likewise, 
multiple internal message brokers could be used to connect multiple sites (or multiple 
levels of firewall security) associated with the TLCL System Provider. 

5 Additional details on the message brokers and their advanced functions 

are contained in a US patent application entitled "Combined Message Broker", Serial 
No. 09/969,369, filed concurrently with the parent application to the present application 
on October 1, 2001, under the attorney docket number 10012320-1, which is hereby 
incorporated herein by reference for all purposes. Further details on the message 
10 brokers and their advanced functions are contained in a US patent application entitled 
"Verified Message Broker", Serial No. 09/969,342, filed concurrently with the parent 
application to the present application on October 1, 2001, under the attorney docket 
number 10012319-1, which is hereby incorporated herein by reference for all purposes. 

These two applications add further detail and scope to preferred 
1 5 embodiments the present invention, and are considered an integral part thereof. They 
also provide examples of the mechanism of interaction of the service engines and other 
related modules, under the present invention. The operation and communication of 
these message brokers (with related disclosed modules), with the TLCL system, 
including the service engines that are incorporate by reference above, define patentable 
20 systems and methods, and are within the anticipated scope of the invention. 

OTHER FEATURES OF THE INVENTION 

In the disclosed embodiment, an application management system, a 
message broker and a set of service modules are described as being within a single, 
global firewall. However it should be understood that the architecture of corporate 
25 networks can take many forms, with multiple layers of firewall or numerous local 
firewalls instead of a single, global firewall. The present system can be implemented 
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in different forms, such as being distributed across various forms of network 
architecture. For example, for the purposes of this description, two network systems 
that are each protected from a public network by a firewall, and that are in 
communication through secure communications channels, are simply one network 
5 behind a firewall, as is discussed above. 

While customers are described above as buyers or sellers, there are other 
entities that might act as customers. For example, Service Activity Providers or even 
Application Service Providers could become customers to provide their respective 
customers with the benefits of the available TLCL solutions. Indeed, such customers 
10 might find the TLCL solution to be superior to their in-house software for some 
purposes, and incorporate the system into their regular procedures. 

It is to be understood that the invention comprises apparatus, software 
and methods for designing setting up, managing and operating service engines, and 
particularly for designing setting up, managing and operating TLCL service engines 
15 and their supporting architecture. Additionally, the invention comprises apparatus, 
software and methods related to using the services of TLCL service engines and their 
supporting architecture. In short, the above disclosed features can be combined in a 
wide variety of configurations and relate to a wide variety of licensees within the 
anticipated scope of the invention. 

While particular forms of the invention have been illustrated and 
described, it will be apparent that various modifications can be made without departing 
from the spirit and scope of the invention. Thus, although the invention has been 
described in detail with reference only to the preferred embodiments, those having 
ordinary skill in the art will appreciate that various modifications can be made without 
departing from the scope of the invention. Accordingly, the invention is not intended 
to be limited by the above discussion, and is defined with reference to the following 
claims. 
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